セキュリティカオスエンジニアリングのオライリー本を読んで学んでいく

最近認知度が広まってきているカオスエンジニアリングですが、2020年12月に情報セキュリティにおけるカオスエンジニアリングについてのレポートが公開されました。 レポートの説明ですが、

• ユーザーは企業に重要な情報を委託しているが、企業は絶えず信頼を維持できていない。
• 毎年同じような攻撃が成功し、影響が大きくなっている。

システムを構築、運用、防御する人はセキュリティ障害が発生することを認める必要がある(間違ったものをクリックする、コード変更のセキュリティ影響は明確ではない) = 物事は壊れる

このような状況下、考え方においてエンジニアがセキュリティをどのようにナビゲートするのかが説明されています。 実験と失敗を利用するためのセキュリティカオスエンジニアリングの基本原則を学び、セキュリティをゲートキーパーからアドバイザーに変える方法を理解していくことが目標です。

セキュリティカオスエンジニアリング(SCE) とは

本番環境の悪意のある状態から防御するシステムの能力に対する信頼を構築するための積極的な実験によるセキュリティ制御の失敗の特定 ※1

• セキュリティメカニズムが、設計した条件下で実行するのに効果的であるという確信を高めることで、継続的なセキュリティ実験を通じて、組織としての準備が整い、予期しない混乱によって不意を突かれる可能性を減らす。
  • セキュリティの未知数に直面したときに,私たち（専門家として）、私たちのチーム、および私たちが代表する組織が効果的で回復力があるように準備する

従来の防御的なセキュリティの考えは障害の回避に固定されていて、失敗は悪の枢軸として見なされるが、このレポートでは失敗が防御的セキュリティにおいて最大の教師であることを提案しています。様々なインシデントに対してよりよく備える方法について我々に知らせる教訓を教えてくれているのだと書かれていますね。

計画された経験的な実験によりシステムの優れたセキュリティを促進する = カオスエンジニアリングを情報セキュリティの分野に適用　というのがSCEです。

重要なセキュリティの過程を検証し、能力や弱点を評価してから能力を安定させ、弱点を軽減するために行動することができるようになる。

レポート内容まとめ

1. Experimenting with Failure (失敗の実験)

カオスエンジニアリングはシステムが正しく動作することを検証するための継続的な実験である。 これらの実験は弱点を明らかにするのに役立ち、顧客が問題に直面する前に未知の障害を発見するための手法をエンジニアに提供してくれる。

重要な考えとして

• レジリエンス※2
  • 回復力のあるシステムは、環境の進化する脅威のコンテキストとともに攻撃と変化を吸収できる柔軟なシステムである
• 堅牢性だけに焦点を合わせると、誤った安心感につながる
  • 失敗を防止しようとしたり、脅威をブロックするための技術的ソリューションのみを実装したりすると、リスクが蓄積され、最終的にはインシデントが発生したときにさらに悪い結果になってしまうことが多い
• SCEは失敗が避けられないことを受け入れ、それを学習の機会として使用するのだ
  • 障害の処理に適切な優先順位をつける。これにより修復するためのコストを削減、顧客への混乱を最小限にする、インシデント中のストレスレベルを減らすことができる。そして、システムの安定性、リスクの理解、運用フィードバックループに対する組織の信頼を高めることができる

繰り返し実験することによって自信を高め、システムの回復力を長期にわたって向上することができる。

障害を阻止しようとするのではなく、障害を適切に処理することがSCEの目標である。

セキュリティは防御的な姿勢から回復力のある姿勢に移行し、完全な予防という不可能な基準を手放す必要がある。

2. Decision Trees—Making Attacker Math Work for You (デシジョンツリー)

セキュリティ戦略を考えるにあたって、攻撃者が操作中にどのような選択を行うかを考えることが不可欠である。 攻撃者の意思決定プロセスを理解することで、驚異を阻止する過剰なエンジニアリングから解放され、攻撃者が侵害しようとしているシステムの問題点を取り除くことに注力できるようになる。

攻撃にも実はROI(投資収益率)が期待されており、attacker mathと呼ばれている。 これを理解することはセキュリティ対策の優先順位を決める上で重要である。

攻撃者の最高のROIオプションを検討することで、攻撃者が実行する可能性が最も高いアクションを発見し、 システムにどのような種類の障害を注入して回復力をテストする必要があるかを明らかにします。

攻撃者は、可能な場合、最も簡単で低コストのパスを選択します

脅威モデリングの決定木(デシジョンツリー)

攻撃者が目標を達成するために特定のサービスまたはシステムで取ることができるさまざまなパス（攻撃者にとって最も簡単なものから最も難しいものをマッピングすることで、緩和策が必要な場所と使用するシナリオに関する視覚的なガイダンスが提供されます。

レポートにはチュートリアルとして 顧客データを含むS3バケットのデシジョンツリーが紹介されています。

参考: 顧客データを含むS3バケットのデシジョンツリー

デシジョンツリーによって攻撃者の考えを先に見出し、最も簡単な攻撃パスに軽減とテストを集中させることで、攻撃者は目標を達成するためにより多くのリソースを使うことになる。これによって攻撃者は気にしないか、より困難な操作を実行する可能性が高くなります。

攻撃コストを上げることがセキュリティの成功の鍵である。

また、フィードバックループを利用して継続的な改善を行うことがだいじです。

デシジョンツリーは、セキュリティ戦略を通知するために継続的に使用でき、使用する必要があります。 それらは、失敗から学ぶためにSCEで実験を行うための出発点を表すことができます。

3. SCE versus Security Theater—Getting Drama out of Security (SCEとセキュリティシアター)

セキュリティシアター

具体的で前向きなセキュリティ結果を生み出すのではなく、セキュリティの向上という認識を生み出す作業。

知覚された失敗に対して個人を罰することを意図した手順は、失敗から学ぶ能力を窒息させ、そもそも実験を思いとどまらせる。

セキュリティはゲートキーパーとして機能することになる。

セキュリティシアターの原則と比較したSCEの原則

SCE	セキュリティシアター
失敗は学習の機会	厳格なポリシーとテクノロジーを強化して、人的障害の帯域幅を削減
失敗は避けられず、非難は逆効果であることを受け入れる	問題の原因として人間を非難
実験と透過的なフィードバックループを使用して、障害の影響を最小限に抑える	ポリシーとコントロールを使用して、障害の発生を防ぐ
セキュリティチームは、協力的かつオープンに運営されている	セキュリティチームはサイロで運営されている
コラボレーション、実験、およびシステムレベルの改善を奨励	「いいえ」と言って最適化を狭めることを奨励
継続的な学習と実験の文化を作成	恐れと不信の文化を作る
原則に基づいており、デフォルトで適応される	ルールベースであり、デフォルトは現状のまま
高速で透過的なセキュリティテスト	手動のセキュリティレビューと評価

SCEは結果が全てであり、現実の世界に最適化された戦略を実験する。理想的なセキュリティが唯一の優先事項ではない。

フィードバックループがなければ、セキュリティ戦略を継続的に改善することは困難である。

セキュリティ承認パターン

外部の承認者としてセキュリティチームに依存すると、ボトルネックが発生します。 これにより、大量の作業が促進され、変更の展開にかかる時間が長くなります。どちらも安定性が損なわれる。

関連するチームが承認パターンの開発に関与していることを確認し、ローカライズされた変更を容易にするプロセスを設計し、 セキュリティチームをアドバイザーとして使用することで、変更を作成するチーム間の説明責任を促進することがSCEの承認パターン。

4. Democratizing Security (セキュリティの民主化)

民主化されたセキュリティプログラム = 誰もが利用できるメリットを備えた、幅広い自発的な参加によってサポートされるセキュリティプログラム

セキュリティへの取り組みが明確に孤立しておらず、排他的でもないことを意味している。

代替分析(防御側の重要な機能)

現代の情報セキュリティでは、代替分析の機能は通常、軍事領域から定義を借りることができるレッドチームによって実行される。

• レッドチーム
  • 作戦環境（OE）の文脈の中で、またパートナー、敵対者、その他の者の視点から、計画、作戦、コンセプト、組織、能力の代替案を十分に検討する独立した能力を指揮官に提供する機能

最終的な目標は

• 環境の理解を広げることで組織の意思決定を改善する
• 計画中の仮定に挑戦すること
• 代替的な視点を提供すること
• アーキテクチャ、設計、ツール、プロセス、およびポリシーの潜在的な弱点を特定すること
• 潜在的な次のステップの影響（特に敵がどのように反応するかについて）を予測こと

計画と運用中に建設的な批判を提供し、思考と行動の両方で敵をエミュレートする (別の視点を検討することで、より強力なセキュリティ結果がサポートされる)

組織内で、既存の仮定に挑戦し、セキュリティの意思決定を改善するための二次的思考をサポートする (attack math を民主化する)

セキュリティチャンピオンプログラム

セキュリティの領域で追加の責任を負うエンジニアリングチームの1人以上の既存のメンバーが関与する一連のプロセス。

目標は、エンジニアリングチームとセキュリティチームの間で、より正確で一貫性のある通信パイプラインを作成すること

エンジニアリングチームは、セキュリティチームの指導の下で、構築および運用するシステムのセキュリティに関する決定を下します。 組織は効率を高め、セキュリティの成果を向上させ、セキュリティの課題はエンジニアの日常的な責任の一部と見なされています。

5. Build Security in SCE (SCEでセキュリティを構築)

セキュリティ障害について考えるとき、ビルドフェーズの後に発生するデータ侵害などの状況について考える傾向がありますが、 セキュリティ障害は、ソフトウェアとサービスの設計と開発から始まります。

ビルドフェーズでの失敗

セキュリティテストツールとそれらを操作する人々が完全に実行されることは決してありません。ので、システムはこの障害を想定して設計する必要がある。

システムがビルド時のセキュリティ障害をどのように処理するかを明らかにするためにどのような実験を行う必要があるかという質問の例;

• 脆弱性スキャナーまたはその他のビルド時セキュリティツールが停止した場合はどうなりますか？
  • PRのマージを停止しますか？
  • リリースは凍結されていますか？

単一のツールが単一の障害の原因になることを許可しない。

脆弱性のリストをチェックすることに焦点を合わせると、本質的にセキュリティを向上させることができる設計の選択に注意が向けられなくなる。

運用前のセキュリティは脆弱性だけではなく、設計ミスは、脆弱性を悪用するよりも攻撃者に簡単なパスを提供しますが、脆弱性中心のセキュリティプログラムでは見過ごされがちです

コンテナとイメージリポジトリでのアプリケーションセキュリティの失敗,

ビルドパイプラインのセキュリティ障害

を例にし、これらの障害をSCEのシステムに注入する方法が挙げられています。

マイクロサービス環境とビルドパイプラインの早い段階で実験を実施す流ことが重要。 テストは、SDLCの早い段階で障害を表面化し、設計によるセキュリティを向上させるフィードバックループを作成するのに役立ちます。 自動化サーバーなど、さまざまなコンポーネントを相互に接続するツールを含め、システムの観点からセキュリティを構築することを検討しよう。

6. Production Security in SCE (SCEでの本番セキュリティ)

本番セキュリティとは、展開段階から始まり、ソフトウェアやサービスの継続的な運用を含むソフトウェア配信のセキュリティを指す。

さまざまな業界の組織で収益を生み出すためには、本番環境でのソフトウェアの展開と運用が急速に不可欠である。 障害は、顧客対応サービスの停止を意味し、直接かつ即座に収益の損失につながるので怖い、しかし障害は稼働中のシステムがインシデントを適切に処理し、スムーズに回復できるようにするための貴重なツールでもある。

おそらくチームは開発環境またはステージング環境からテストを開始することを好むが,SCEプログラムはこれを初期移行期間とみなし、本番環境にカオステストを移行する計画を立てる必要がある。

本番システムが特定の障害状態にどのように対応するかをプロアクティブに理解する唯一の方法の1つは、本番環境でカオスエンジニアリングテストを実施することなんだ。

The DIE Triad

セキュリティの将来のニーズについて考える別の方法。 システムを保護する方法について、3つの新しいパラダイムを提唱している。

• 分散型
• 不変
• 一時的な属性

これは、セキュリティを促進するシステム特性を強調している。

従来のパラダイムは機密性、整合性、可用性で CIA Triad として知られている。 抽象的なセキュリティ目標を強調している。

不要なシステムやデータを最小限にし、攻撃に対するリスクを減らすということ？

本番環境でのシステム障害

実稼働環境でのセキュリティカオス実験の例が示されています。

ほとんどの本番インフラストラクチャはLinuxで実行され、Linuxシステムでは、すべてがファイルです。その観点から、セキュリティ障害は、システムに意図しない悪影響をもたらすファイルの作成、削除、または変更と見なすことができます

実稼働環境でのセキュリティカオス実験

失敗から早期に学ぶためにカオス実験を実施することは、継続的なビジネスの安定性をサポートするために不可欠である。

本番システムのコンポーネント間の関係を発見することは、セキュリティカオス実験の重要な利点です。 1つのリソースの侵害をシミュレートすると、それに接続されているどのリソースも影響を受ける可能性があります。 Productionコンポーネント間の関係を特定することは、伝染の可能性を減らすのに役立つ。

7. The Journey into SCE (SCEへの旅)

セキュリティ業界は、単に「インシデント」に「対応」するだけで、システムの復元力を積極的に強化する機会として、これらのインシデントをさらに理解し、育成する貴重な機会を見落としています。

インシデントを積極的かつ意図的に開始して、その影響を学習し、適切な自動応答を設計するとしたら？

既知の仮定の検証に焦点を当てる

既知のシステム上の弱点または「手に負えない成果」が蔓延しているため、悪意のある攻撃者は引き続きシステムを侵害することができます。 これらの状況は、一般的に知られている事故、間違い、エラーにセキュリティインシデントの形で対応するのではなく、 積極的なセキュリティ実験を通じてシステムの復元力を積極的に強化する機会を与えるので重要である。

セキュリティカオス実験の作成

SCEは、システムのセキュリティを説明するために、厳密な実験を通じて可観測性を導入する。 システムにセキュリティイベントを注入することで、チームはシステムがどのように機能するかを理解し、回復力を向上させる機会を増やすことができる。

実験計画プロセスに貴重なカオス実験を作成するプロセスが明記されている。

SCEゲームデイを行う

SCEの使用を開始するにあたり、実弾射撃訓練中に手動で失敗を注入することにより、SCEゲームデイは練習から価値のある結果を生成し始めるための優れた方法である。

目的は、セキュリティコンポーネントに関連する一連の仮説を作成し、実験を計画し、実験を実行して、それらの仮説を検証または反論すること。

SCEゲームデイについて記載されている。

セキュリティアーキテクチャ、セキュリティ監視、インシデント対応などのユースケースが紹介されています。

SCEツール

• ChaoSlingr
• CloudStrike

といったツールが紹介されています。

8. Case Studies (ケーススタディ)

SCEの実装に成功した組織からのいくつかのケーススタディの共有。

• Applied Security—Cardinal Health
  • パブリッククラウドに移行する際に、理論的セキュリティアーキテクチャに依存して保護することはもはやないと判断
  • セキュリティの有効性をより客観的に測定する必要性から、プロアクティブなセキュリティテストと実験のビジネスケース、つまり「応用セキュリティ」と呼ばれるものが生まれた。
  • SCEのCVVコンセプトを会社に提供する手段となった
• Cyber Chaos Engineering—Capital One
  • サービスの中断に対する回復力に焦点を当てるのではなく、真の現在の状態を特定し、「通常の」操作とは何かを判断することに焦点を当てた
  • 最初はスコープを小さく保ち、エンドポイントアラートの上位10サブセットのアラートと検出機能の検証のみに焦点を当てていた
  • 集中力を維持することで、チームはセキュリティの優先順位の高いサブセットを実験し、成功を実証する能力をすばやく支援することができた

最後に

レポートの内容を簡単にまとめただけでの記事ですが、情報セキュリティにカオスエンジニアリングを適用する方法、利点などが学べました。

レポートにもこれは適切であるだけでなく、不可欠であると結論づけられており、安定性と信頼性の両方を保証できるようになるとされています。

導入するにあたっての障壁は高そうに感じますが(セキュリティの考え方がかなり変わるため)、実験で学ぶという点ではエンジニアの育成においても重要になってくるのではないでしょうか？ ぜひセキュリティの専門家の意見も聞きたいです。

注釈

1.Security Chaos Engineering

Security Chaos Engineering：A New Paradigm for Cyber​​security

2.レジリエンス

脅威やストレスから回復するだけでなく、さまざまな条件下で必要に応じて実行し、障害と機会の両方に適切に対応する能力